枚举的第一个过程是rc端通过向bus上发起配置空间访问获取整个总线拓扑上的设备信息。

简单说来就是去遍历每个bus，以及bus下device的配置空间。如果读到有效的device ID值（非全F）则认为发现了可用的设备。

bus device function这3个number的分配是很有意思的事情。对于每个pcie设备来说，配置空间中并没有寄存器可以用来配置或者修改bdf number。那么这3个值在到底是怎么确定的呢。

经典的说法是，bdf number是由pcie总线的硬件拓扑来决定的。这个说法按照pcie的规范来说没有问题，但前提条件是必须先按照规范对整个总线进行枚举。在枚举之前，实际上每个设备的bdf number是不确定的。[注1]

function number是用于多function设备用于区分设备中具体访问的是哪个function的。那么对于大部分单function的设备来说，function number就固定为0；对于多个function的device或者支持虚拟function的device，function number也是由device内部来进行管理和区分的，不需要通过总线枚举来确定。

为支持ＩＤ路由，每个PCIE设备（端点和交换开关）中都应设置有贮存设备总线号和设备号的寄存器，复位时，该寄存器清０，每当设备在它的原级链路上检测到一个Type0的 config transaction 事务包时，它就从该TLP头标中的第８～９字节“捕获”总线号和设备 号作为它自己的bus和device号，并贮存入上述总线号和设备号寄存器。所以说在接收至少一个 Type0配置访问事务包以前，设备不会响应除配置周期以外的任何事务。PCIE协 议中没有定义贮存总线号和设备号信息的配置空间单元，只是规定了它必须做这件事。

两个对接的PCIE设备，主设备是RC端，从设备是EP端，那么上电复位后，EP是如何获取自身的bus number的呢？

在这样的一个PCIE结构中，上电复位后，RC端发起一个对EP的配置访问事务，EP会解析配置请求中的bus number，并保存下来，作为自身的bus number号。之后就可以相应其他TLP事务了。也就是说，上电复位后，EP必须先接收到一个配置请求，然后才能响应其他TLP事务。

@【注1】，这里提一点，如果没有按照规范对设备进行枚举。对于rc直接接一个ep device的情况，在裸机的环境下实际上rc的driver可以为对端ep分配任意的bus和device number。因为pcie是点对点连接，第一笔Type0的 config transaction 事务的bus和device number无论是何值，都会被对端ep接收到，并保存下来作为自己的bus和device number。后续用这个bus和device number就可以访问对端的ep设备，直到ep设备复位。

前面内容已经说明了一个设备的bdf number的确定，那么枚举的过程也就是rc的系统软件通过配置空间访问来确定以及扫描整个总线拓扑的过程。